home *** CD-ROM | disk | FTP | other *** search
/ Aminet 52 / Aminet 52 (2002)(GTI - Schatztruhe)[!][Dec 2002].iso / Aminet / comm / irc / epic4.lha / doc / TS4 < prev   
Text File  |  2002-09-18  |  6KB  |  131 lines
  1. This is the status of the TS4 implementation:
  2. *) I'm a client coder; what should my client do to support TS4?       
  3.  
  4.         TS4's new features have been designed to avoid confusing older  
  5.         clients whenever possible.  ircII, EPIC and sirc all mostly work
  6.         with TS4 without modifications [someone needs to check the
  7.         Windows and Mac clients; I can't.]
  8.  
  9.         Still, there are a number of ways a client (or script) can      
  10.         explicitly support TS4, to make things easier for the user. 
  11.  
  12.         1) The very basics, that every client should do:
  13.  
  14.         .  When parsing mode changes, it's good to know that +h and +e   
  15.            take an argument.  Clearing channels sets mode +z temporarily
  16.            (as in "zapped channel"), so the client shoulnd't crash on
  17.            seeing a mode +z or -z either.
  18.  
  19. --> The client fully supports the +h <nick> channel mode.
  20. --> The client fully supports the +z channel mode.
  21. --> The client ignores any argument for +e, the same as it does for +b.
  22.  
  23.         .  When parsing NAMES, WHOIS and WHO replies, it's good to know
  24.            that '%' is a user flag, and that more than one flag can   
  25.            appear at a time (so you can have things like "@%+nick").     
  26.  
  27. --> The client fully supports multiple user-modifiers in the NAMES reply.
  28. --> The client fully supports all three user-modifiers (@, %, and +)
  29. --> The client may not fully support multiple user-modifiers in WHO replies
  30. --> The client may not fully support multiple user-modifiers in WHOIS replies.
  31.  
  32.         .  The "End of Exception List" numeric shouldn't be displayed
  33.            by default.
  34.  
  35. --> Without knowing what numeric this is, this is not supported.
  36.  
  37.         .  Expect to get PRIVMSGs for @#channel, @%#channel and
  38.            @+#channel, and show them in the same area as the channel's 
  39.            messages (but marked in some way).  Same with @&channel,    
  40.            @%&channel and @+&channel for local channels.
  41.  
  42. --> There is no special support for these targets.  They are handled
  43.     as any other non-channel target would be handled.
  44.  
  45.         .  Do NOT ever automatically deop people opped by servers.  This 
  46.            is the best and easiest way to end up with an opless channel,
  47.            and it defeats the whole purpose of channel passwords and op
  48.            recovery.
  49.  
  50. --> The client does not automatically deop anyone, ever.
  51.  
  52.         .  If your client kicks people from banned addresses, make sure
  53.            it also checks against exception lists (mode +e).
  54.  
  55. --> The client does not automatically kick anyone, ever.
  56.  
  57.         .  Expect 3 parameters rather than 1 from numeric 329
  58.            (RPL_CREATIONTIME);  see also the list of changed and added
  59.            numerics on README.TS4.
  60.  
  61. --> The client fully supports three arguments to the 329 numeric, if present.
  62.  
  63.         2) Possible additions:
  64.  
  65.         .  If the client has ban management functions, the same
  66.            functions should be offered to manage exception lists.     
  67.  
  68. --> The client does not have ban management, so no change is required.
  69.  
  70.         .  There should be a command or button to join a channel using a
  71.            password, prompting the user for the password without        
  72.            displaying it on the screen.
  73.  
  74. --> The client already permits passwords in the /join command, so no change
  75.     is required.
  76.  
  77.         .  Even better, a list of known passwords could be saved to a
  78.            file (readable only by the user); the client would then use
  79.            the saved password (if there's one), instead of prompting.
  80.            The user should have a way to add, remove and change elements
  81.            in the list, from within the client.
  82.  
  83. --> The client does not manage or store passwords on any permanent medium,
  84.     and no intention to change this is planned.
  85.  
  86.         .  Whenever the client sees a "mode +c" on a channel, it could
  87.            query the server for the password, and remember it.  It
  88.            should _not_ show it on the screen by default (you don't want
  89.            passwords shown automatically when there could be someone
  90.            looking behind the user's shoulder).
  91.  
  92. --> There is no support for this currently.
  93.  
  94.         .  Expect to get PART commands for yourself from the server,
  95.            even if the user has not requested to leave any channels (this
  96.            happens with recovered nick collisions).  For GUI clients,   
  97.            you might want to leave the client a chance to read the   
  98.            channel window contents.
  99.  
  100. --> As the client does not track when the user PARTs a channel, the client
  101.     has no way to know whether a recieved PART was initiated by the
  102.     user.  Thus, no recovery for the channel can be made automatically
  103.     by the client.  Perhaps the designer of this "feature" ought to have
  104.     considered sending a numeric before the PARTs come flowing so as not
  105.     to make it gratuitously difficult to support this.
  106.  
  107.         .  When you get the "nick lost" numeric (453), prompt the user 
  108.            for a new nick, and send an ordinary nick change command to
  109.            the server.  Any commands sent in between can get ignored with
  110.            "not registered" errors from the server.
  111.  
  112. --> The 453 numeric handled just like any other non-disruptive nick collision.
  113.  
  114.         .  Clients should be able to handle reconnection cookies
  115.            automatically: whenever you connect to a server and get back
  116.            a cookie (with the numeric 014, "<cookie> :is your  
  117.            reconnection cookie"), the client should store the cookie,  
  118.            along with the server name and the current time, in a file. 
  119.            At that same moment, the client should look if there is a
  120.            previously saved cookie for that server; if there is one,
  121.            delete it from the file, and send it to the server, unless it 
  122.            is more than 10 minutes old.
  123.  
  124. --> The client will remember cookies from previous connections and will
  125.     always send the cookie upon the next connection.  The client makes
  126.     no attempt to determine if the cookie is "too old" to be used.
  127.     The client makes no attempt to store cookies on a permanent medium
  128.     for use by a subsequent client.
  129.  
  130. Last updated, November 17, 1998.
  131.